Date: Thu, 20 Oct 94 04:30:24 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: List 

Subject: Ham-Digital Digest V94 #346 

To: Ham-Digital 


Ham-Digital Digest Thu, 20 Oct 94 Volume 94 : Issue 346 


Today's Topics: 
ampr.org conventions? 
Does a TM 732 E/A can work at 9600 bauds ? 
FBB or MSYS mailing lists??? 
GPS prices? 
NOS: problem with ALIAS file 
RTTY ? 
Send .COM files over e-mail 
WANT: Computer Aided Dispatch system 
Where is "“ethrax25.zip"? 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Thu, 20 Oct 1994 02:45:43 GMT 
From: kf£5mg@metronet.com 
Subject: ampr.org conventions? 


In <38391j$pt3@uk-usenet.uk.sun.com>, smckinty@sunicnc.France.Sun.COM (Steve 
McKinty - SunSoft ICNC Grenoble) writes: 

>I have several systems tied together on a home ethernet. I want to 

>assign a domainname covering all of them, within the ampr.org domain. 

> 

>Assuming I get the appropriate IP addresses, what is the convention 

>for this? Would a domain of <mycallsign>.ampr.org be normal, with 

>the systems configured as <system1>.<mycallsign>.ampr.org etc.? 


Brian Kantor ( brian@nothing.ucsd.edu I think ) will have the right answer 


since he runs the ampr.org dns. I've been doing slip.callsign.ampr.org or 
linux.callsign.ampr.org, etc for local users. No one's complained yet. 
Check with Brian if your worried. 


73's de Jack - ktf5mg 
Internet - kf£5mg@kf5mg.ampr.org - 44,28.0.14 

- k£5mg@metronet.com - work (looking for) 
AX25net - kf5mg@kf5mg.d#dfw.tx.usa.noam - home (817) 488-4386 
~SSSS2SS25S3SSSSS 323 SSS S3 22 SSS2S SESS SSS ESSE SSS ESS SSE ESS Sqeea Hy 
+ D.A.M. - Mothers Against Dyslexia + 
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Date: 20 Oct 1994 08:07:24 GMT 
From: jcmonier@muguet.saclay.cea.fr (KENWOOD) 
Subject: Does a TM 732 E/A can work at 9600 bauds ? 


First, thanks to read this news, 


Subject say all but I'm added these details : 


- does someone have make some homebrew about that ? 
- if the TM 732 can work at 9600 is it directly (original featured) 
or with a particular mod. 


- notice I have a 732 E on witch I av perform the E5 mod (see file 
T™732.mod in /pub/hamradio/mods/kenwood on oak.oakland.edu) 


Thanks and 73 to all 


Jean-Christophe MONIER 

Ingenieur Reseaux / Networks Engineer 
Athesa - C.E.A. Defense - France 
E-Mail : jcmonier@muguet.saclay.cea.fr 
Phone : (33/1) 69.08.56.41 


Date: Wed, 19 Oct 1994 12:44:45 GMT 
From: rumbalj@govonca.gov.on.ca (John Rumball) 
Subject: FBB or MSYS mailing lists??? 


Thank you for reading this posting. I am wondering if there are any FBB or 
MSYS related mailing lists I can subscribe to, similar to the NOS-BBS list? 


If you know of such a list, please pass along the details (ie. how to 
subscribe) to me. 


Thank you in advance and 73. 


de John, VA3BUS 


/------ \ Ontario JOHN RUMBALL 

| OQ | Ministry of District Systems Officer rumbalj@gov.on.ca 

| () | Natural Sudbury, ON Canada va3bus@va3bus.d#ne.on.can.noam 
\rcree- / Resources (705) 722-7823 ext.278 


Date: Thu, 20 Oct 1994 02:50:23 GMT 
From: k£5mg@metronet.com 
Subject: GPS prices? 


I'd like to play with mobile packet and GPS maping. Anyone know where 
I can find a REALLY cheap GPS device with a built in serial port? Thanks. 


73's de Jack - kif5mg 
Internet - kf£5mg@kf5mg.ampr.org - 44.28.0.14 

- kf5mg@metronet.com - work (looking for) 
AX25net - kf£5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 
-_2SS25S S555 5555 SSS SSS S555 2255S S255 555555555555 55S SS SSS SS 
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Date: Wed, 19 Oct 1994 17:24:00 GMT 
From: boulaisg@ingenierie.telecom.hydro.qc.ca (Guy Boulais) 
Subject: NOS: problem with ALIAS file 


Hi, in my ALIAS file of NOS I made an entry like this: 
joe fred@abc123.edu 


When I try to send a mail to "joe", the smtp module tries to send the 
mail to abc123.edu, but to user "joe" instead of "fred". So the 
receiver returns me a message telling that user "joe" is unknown. 


I am using NOS11C-A.EXE 


Is there any parameter to adjust that? 


THANKS!!! 


Guy Boulais, VE2GYB 
e-mail: boulaisg@ingenierie.telecom.hydro.qc.ca 
e-mail: ve2gyb@ve2ums.ampr.org 


Date: Wed, 19 Oct 1994 23:09:04 GMT 
From: morris@grian.cps.altadena.ca.us (Mike Morris) 
Subject: RTTY ? 


FOR SALE, TRADE, OR ???? 


One Model 28 ASR Teletype, complete. 
Includes spare Model 28 RO less cabinet 
i.e. a spare printer mechanism with base. 


The 28 ASR has a regular friction feed platen. 
The 28 RO is equipped with a pin feed platen, 
vertical and horizontal tab kits (was used to print 
airline tickets). If you really want it I have the 
Teleticketer (tm) control box - essentially a 300 baud 
autoanswer modem with answerback and a loop current generator. 


This unit has been in storage in the back of my garage for the last 
5-6 years when the current owner moved from a house into an 

apartment and asked if he could store it in my garage. I believe it 
was working at that time. He has since lost interest in it, and told 
me to get rid of it. Manuals _might_ be available - if any interest 
is shown, I will put the prospective buyer in touch with the current 
owner. 

Mike Morris WA6ILQ | 
PO Box 1130 | 
Arcadia, CA. 91077 | 
ICBM: 34.12N, 118.02W | 


All opinions must be my own since nobody pays 
me enough to be their mouthpiece... 


Reply to: morris@grian.cps.altadena.ca.us 


Date: 19 Oct 94 19:44:54 GMT 
From: byon@quicksilver.COM (Byon Garrabrant) 


Subject: Send .COM files over e-mail 
Send .COM files over e-mail and packet 


brian@nothing.ucsd.edu (Brian Kantor) writes: 

>Or better yet, instead of using UUENCODE, which uses characters that 
>aren't going to survive some e-mail gateways, use the MIME standard 
>that does. Why gosh-golly, if you use one of the standards, you might 
>even find that you don't have to write code to use it, because your 
>mailer might already understand it. 

> 

>But then, being compatable and following standards would take all the 
>fun out of it, eh? That's why we're AMATEURS, right? 

>- Brian 


I believe that unless the recipient of the file/message has a MIME 
decoder, they will be completly unable to use a MIME file sent to them. 
There may be many Internet e-mail reader which automatically de-MIME 
thnigs for you, be I'd bet very few hams on packet have even HEARD of 
the MIME standard. CODET's purpose is to facilitate the sending a 
binary file when the recipient has no more software than a terminal 
program and a text editor. It's a little different than MIME's 
purpose. I suppose I could have written the program to decode a MIMEed 
.COM file, but I have seen UUENCODE used more than MIME, I don't know of 
any packet TNC's that won't pass the characters I used, and what 
difference does it make to the end user? 


73, Byon 


Byon Garrabrant KD6BCH byon@quicksilver.com 


Date: Thu, 13 Oct 1994 08:17:22 -0400 
From: CSLE87@email.mot.com (Karl Beckman) 
Subject: WANT: Computer Aided Dispatch system 


In article <3792jm$sdt@www.interramp.com>, pp000814@interramp.com wrote: 


I would like to know what info turns up here. Several people who work for me 
will be attending a meeting at the Dulles Marriott this week to discuss 911 


service for PCS and Celluar users. 


VV VV VV VV 


> 
> In article <CxBn4C.7yB@peacock.tcinc.com>, <sjames@tcinc.com> writes: 
> > Newsgroups: rec.radio.amateur.digital.misc 

> > Path: 


interramp.com!psinntp! rutgers!netnews.upenn.edu!msuinfo!caen!spool.mu.edu!sol.c 
tr.columbia.edu!news.msfc.nasa.gov!news.larc.nasa.gov!lerc.nasa.gov!purdue! yuma 


!csn!nowhere!aitsun20!sjames 

From: sjames@tcinc.com (Scott James) 

Subject: WANT: Computer Aided Dispatch system 

Message-ID: <CxBn4C.7yB@peacock.tcinc.com> 

Sender: news@peacock.tcinc.com (Internet News Administration) 
Nntp-Posting-Host: aitsun20 

Organization: TeleCommunications, Inc. 

X-Newsreader: TIN [version 1.2 PL2] 

Date: Fri, 7 Oct 1994 21:16:59 GMT 

Lines: 14 


I'm looking for a Computer Aided Dispatch (CAD) system 
that links radio modem technology with a GIS display. 
These systems are used by Federal Express (I think) 
and 911 agencies. 


If you know of any products or companies that can help 
me find such a system, please email me with the info. 


thanks in advance! 


scott james 
NOLHX 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


VV VV VV VV VV VV VV VV VV VV VV VV 


To the unnamed pp000814 - 

As a subscriber and nationwide roamer using cellular mobile service, I have 
found that every cellular or PCS provider has a different method of 
interfering when I dial 9-1-1 to report a serious problem on the highways. 
There is no reason that direct emergency calls to 9-1-1 should be hindered 
in this way. I found that the wireline cellular carriers in 
Michigan/Indiana publicize their *-1-1 service, but it just goes into a 
continuous ring cycle, and of course nobody answers their "0" lines either 
when you try to report the problem. 


I believe so strongly in universal 911 access that I am planning to author 
a formal request for FCC rulemaking in the near future. So, to get 
directly to your inquiry, what is needed? 


An FCC requirement that every radio-based voice communications service 
provider shall directly route any call to 9-1-1 to the local PSAP 
appropriate for the general area where the call was originated (The same 
algorithms used to provide automatic transmitter site selection based on 
signal strength can be used to provide the call routing data). Further, 
each carrier must provide caller ID information to each PSAP, which is 
already provided for landline callers. Third, a direct callback input shall 
be provided so that every PSAP nationwide has the ability to re-dial and 
re-establish communications to the radio unit without dialing multiple 
carriers, their various switch access codes, and finally the radio 
subscriber's assigned number. In short, radio-based comm carriers must 
have service identical to that provided today by landline telephone 
providers, and at no charge, so that radio-based subscriber units shall 
have equal access to 9-1-1 services. 


Scott - Motorola has provided quite a large number of computer-aided 
dispatch systems, partnering with various software houses and mainframe 
suppliers to build very complex interfaces to the "head-end" dispatch 
center. You should understand that the data protocols used over the air 
for the roaming data terminals are not the same ones you use fearlessly for 
direct hardwire connections. I am aware of some the issues at FedEx, but I 
think you need to talk to professional folks in the radio and computer 
industries, not radio amateurs. 


Karl Beckman, P.E. < If our English language is so > 
Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > 
(Square waves & round corners) < parkway and park on the driveway? > 
Opinions expressed here do not belong to or represent Motorola Inc. 
Amateur radio WA8NVW NavyMARS NNNOVBH @ NOGBN.NOAST 


Date: 19 Oct 1994 15:24:28 -0700 
From: tcj@infoseek.com (Todd Jonz) 
Subject: Where is "ethrax25.zip"? 


About a month or so ago there was a thread running in this group about the 
upcoming availability of device drivers for DOS and/or Windows that would 
support KISS on Winsock. One helpful gentleman (whose name and call I have 
unfortunately misplaced) suggested I have a look at: 


ftp://f£tp.ucsd.edu: /hamradio/packet/tcpip/incoming/ethrax25.zip 


I only just got around to following up on this pointer last evening, and was 

disappointed to discover that this file has been corrupted. Does anyone know 
of another site from which this archive can be obtained? Or if the author(s) 
happen to see this note, perhaps you could repost a clean copy to UCSD? Tnx, 


KB6JXT, Todd 


Date: Thu, 13 Oct 1994 09:00:03 -0400 
From: CSLE87@email.mot.com (Karl Beckman) 


References<Cx9FrL.IxF@world.std.com> <19940ct8.131116.15772@ke4zv.atl.ga.us>, 
<CxFMMA.K8n@world.std.com> 
Subject: Re: 56k+ Packet System 


In article <CxFMMA.K8n@world.std.com>, dts@world.std.com (Daniel T Senie) 
wrote: 


> In article <19940ct8.131116.15772@ke4zv.atl.ga.us>, 

> Gary Coffman <gary@ke4zv.atl.ga.us> wrote: 

> >In article <Cx9FrL.IxF@world.std.com> dts@world.std.com (Daniel T Senie) 
writes: 

> >>In article <36u4fd$56h@push.stack.serpukhov.su>, 

> >>Victor Voronkov <victor@stack.serpukhov.su> wrote: 

> >>>Exich Muschinske (erich@enterprise.CHinalake.navy.MIL) wrote: 

> >>>> Don't be too fast to dismiss this idea. One of the things packet 
networking 

> >>>> desperately needs is a cheap high speed data link. This is necessary for 
> >>>> operating a cellular packet concept. It would only have to work with the 
> >>>> radio on the other end, so adapting would not be out of the question. If 
> >>>> the price of a link could come down to about $600, I would be very 
interested. 

>>>IMHO any attempt to get speed more than 9600 on HandHeld or other ‘voice’ 
>>>Radio is problem. Even if we find new modulation. With half-duplex 

>> 

>>Can I ask a question here? How is it possible to get the necessary S/N ratio 
>>and other such to get a V.32bis modem to operate correctly over a Cell Phone? 
>>It seems to me that it IS possible for cell phones to provide a clean enough 
>>signal to do data over them, so why do hams have so much trouble getting 
>>the needed S/N ratio to run at 9600? I must really be dense and missing 
>>something. I understand that the example of V.32bis (14.4kbps) over cellphone 
>>is point-to-point. So are most amateur 56K links. Why can't we do a high 
>>speed link over inexpensive gear and limited bandwidth? It seems to work 
>>for cell... 

> 

>You xarex missing something Dan. It's not SNR that's the problem. While 

>it's true that most ham HTs are sorely lacking in adequate SNR over many 
>paths for xanyx type of modulation, including voice, hence the term handi- 
>scratchie, that's *xnot*x the main problem. Cellular phones are like the 

>rest of the telephone system in that the phone network handles the addressing 


VV VV VV VV VV VV VV VV VV 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


>and routing xout of band*. This means that when the phone rings, the modem 
>xknows* the signal is for it, and can initiate a *training* sequence with 
>the modem on the other end to equalize and utilize the one transmission 
>path then in use. It is an xexclusivex circuit with no other modem signals 
>present. 


Most of the high speed packet usage I've seen has been for dedicated point- 
to-point links. At least that's the case up here in the northeast. When 
that IS the case, the issue of multiple signals goes away (or let's assume 
so for the sake of discussion). 


Assume two radios of known manufacture (and same brand and model just to 
ensure all is the same). Assume FULL DUPLEX on two frequencies, so that 
both ends are ALWAYS keyed and transmitting. This eliminates the call setup 
issues. 


Now, I still do not understand how a cell phone can get 14.4kBPS through 
a channel where we could not do the same on a dedicated, full duplex 
circuit. 


I understand fully the switching mechanisms, dedicated point-to-point nature 
of telephones, and the like. What I really want to hear more about is the 
actual data over a voice grade telephone circuit part of things. 


> 

>The only difference that a cellular modem faces versus wireline modems 
>is occasional signal dropouts due to handoffs, and the usual multipath 
>concerns. Therefore special modem parameters have to be used such as slow 
>disconnect so that the modem won't drop the connection during a brief handoff 
>outage, and robust error detection to handle the multipath induced symbol 
>errors. We already have all that in packet. 

> 

>What we xdon't*x have on packet is out of band routing and addressing, 
>and what we xdon'tx have on packet is *exclusivex use of a frequency 

>for a pair of stations. A packet modem has to successfully decode the 


We do have many dedicated frequency links up here. 


>header of xeveryx packet on the channel to assure that the packet either 
>is or is not addressed to it. It *cannot*x initiate a training sequence 
>every time it hears a packet it can't decode. xThat'sx why packet modems 
>can't use training, and training is the key to high speed data over a 
>voice grade circuit. Every telco modem over 2400 baud uses some form 

>of training at call setup. In packet, setup must be on a packet by 
>packet basis, and that won't work because not all packets on the 
>channel are addressed to the same modem. 


So if we were to construct equipment for dedicated links as I described 


VVVVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VW 


VVV WV 


above, and used training, then we'd be able to get 14.4K or 28.8k data 
rates over a 3kHz wide voice passband? (again assuming the dedicated 
pair of frequencies, and RF gear of known design). 


> 

>With the typical Kenmore, Yahoo, Icky, and Motrash radios used by 
>amateurs, no two of them will have the same bandpass characteristics. 
>Training is xessentialx to compensate for that, and for off channel 
>stations. Amateur equipment doesn't have the frequency stability of 
>commercial equipment, so it isn't unusual to have one or more radios 
>a kilohertz or more off channel. Nor is it unusual to see wide differences 
>in deviation from one radio to the next, even among those of the same 
>make and model. Any modulation used has to be tolerant of all those 
>errors *xwithout* compensation on a packet by packet basis. That's why 
>systems as slow as 9600 baud are difficult to setup with more than 
>two stations. 2400 baud is about as fast as an uncompensated system 
>can work with multiple players. 

> 

>The limitation is *xnot*x with the modems, it's with the *xradiosx. 

>To successfully use high speed packet, we xmust*x have radios with 
>identical response characteristics, and that means dedicated data 
>radios, all optimized for the xsamex response. Now it may be possible 
>to compensate xallx radios the same way in a system by use of DSP, 
>but it's not likely. There are two many variables outside the control 
>of the DSP, such as whether the radio is on channel center or not, 
>and the differing multipath from one radio path to the next. We 

>need identical radios, xand* a modulation that is tolerant of certain 
>types of errors. Such systems exist, I keep pointing to the GRAPES 
>56kb RF modem as an example, but insistance on using voice grade 
>amateur equipment for high speed packet is futile. Amateur packet 
>networks are xnot*x like the telco network, and telco techniques 
>won't work. 


I guess I'd always assumed that the GRAPES stuff was used to build backbone 
links of a network. From the issues you raise, it appears that this is 

a misconception, and that you have set up networks of multi-access 

stations over GRAPES modems at 56K. Is this correct? 


Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compusetrve: 74176 ,1347 


Gary, please pardon me if I put words in your mouth. I've been tracking 
the thread for a while and I agree with both your goals and implementation 
plan. 


Dan, I think you missed some of the most basic principles that Gary has 
been trying to make to the amateur community for several years now; 


1) You MUST build high-speed networks out of units that perform 
consistently, predictably, and in a nearly identical fashion. If you 
don't, you spend more time in establishing and maintaining the circuit than 
in moving the data. 


2) GRAPES is not a just modem, not just a radio, not just a digital (ONLY) 
modulation method. It IS an integration of all three items into a package 
with documented, useable (and rather impressive), and repeatable 
performance parameters. 


3) Amateur radio packet networks are BY DEFINITION multipoint networks 
that must operate reliably while having non-exclusive use of the radio 
channels. Data links made through telephone networks, conversely, are not 
shared and are not multi-point. 


Karl Beckman, P.E. < If our English language is so > 
Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > 
(Square waves & round corners) < parkway and park on the driveway? > 
Opinions expressed here do not belong to or represent Motorola Inc. 
Amateur radio WA8NVW NavyMARS NNNOVBH @ NOGBN.NOAST 


End of Ham-Digital Digest V94 #346 
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